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(57) Abstract: Data communication 
system and a method in a data 
communication system comprising 
a terminal (2), e.g. a mobile phone, 
adapted to communicate with an 
application server (4) using a wireless 
U:ansmission protocol, preferably WAP, 
also includes an attached device's profile that is dynamically 
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Profile and capability of :7AP-terminal 
with external devices connected. 



Field of the invention 
5 The present invention relates to a data communication system and a method in 
a data communication system in accordance with the preambles of the 
independent claims. 

Background of the invention 

10 

Wireless Application Protocol (WAP) is a technology that enables wireless access 
to Internet applications from a terminal, preferably a mobile phone. 
Th#* WAP fnnim available at www.v^pfomm.oro, has ddSned a WAP architecture 
for pulling (i.e. user initiated) information from Internet (e.g. Internet browsing) 
15 and pushing (i.e. application initiated) information (e.g. sending news messages, 
mail notification). 

Wireless Application Environment (WAE) has adopted a model that closely 
follows the World Wide Web (WWW) model. All content is specified in formats 

2 0 that are similar to the standard Internet formats. Content is transported using 

standard protocols in the WWW domain and an optimized HTTP-like protocol in 
the wireless domain, a WAP communication protocol, preferably the Wireless 
Session Protocol (WSP). WAE has borrowed from WWW standards induding 
authorizing and publishing methods ^erever possible. 

25 

The WAE assiimes the existence of a WAP gateway with functionality responsible 
for encoding and decoding data transfeired from and to the terminal. The 
pxirpose of encoding content delivered to the terminal is to minimize the size of 
data sent to the terminal over-the-air as well as to minimize the computational 

3 0 energy required by the terminal to process that data. 

The major elements of the logical WAE model is a terminal including a WAP user 
agent that wirelessly communicates with a gateway that includes encoders and 
decoders. The WAP gateway in turn communicates with an or^in server 
including server applications. 
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A WAP user agent is defined as any software or device that interprets content 
(e.g. Wireless Markup LangU£^e, WML) and may include textual browsers, voice 
browsers, search engines, etc. 

5 Capability and Preference Information (CPI) may include hardware 

characteristics (screen size, color capabilities, image capabilities, etc.), software 
characteristics (operating sjrstem vendor and version, support for used 
programs, list of audio and video encoders, etc.), application/user preferences 
(browser manufacturer and version, markup languages and versions supported, 
10 scripting languages supported, etc.), WAP characteristics (WML script libraries, 
WAP version, WML deck size, etc.) and network characteristics (bearer 
characteristics such as latency and reliability, etc.). 

A User Agent Profile (UAProf) specification extends the WAP to enable end-to-end 
flow of a UAProf between the terminal, the intermediate network points and the 
1 5 origin server. UAProf is using capability and preference information as a set of 
components and attributes. UAProf is transmitted over wireless networks within 
WSP headers. 

In 8\immaiy the UAProf is concerned with capturing classes of terminal 
20 preference information. These classes include the hardware and software 

characteristics of the terminal as well as information about the network to which 
the terminal is connected. 

Figure la shows schematically how a terminal 2, e.g. a mobile phone, 
25 establishes a mobile Internet session with an application in an application server 
4 according to a well-established technique used today. Figure lb shows a block 
diagram of the UAPirof 6 including a terminal profile 8 used in figure la. 

When a terminal establishes a mobile Internet session with an application, it wiU 
30 send its User Agent Profile to this application. This profile contains the attribute 
values of the terminal and/or references (e.g. in the form of an Intemet-address) 
to the application server(s) where the attribute values can be found. 
The scenario described in connection with figure 1 shows the opening of a WSP 
session and establishing of an initial UAProf. Upon opening a WSP session, the 
3 5 UAProf-aware terminal conveys its profile information using Profile and Profile- 
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3 

Diff headers within the WSP connect request The values of these headers are 
constructed by encoding the CPI. 

While a UAProf-aware session is established, the client (terminal) may update 
5 the active UAProf at any time. To do this, the terminal transmits a WSP session 
resume message to the WAP gateway containing Profile and Profile-Diff headers 
with the new CPI. 

Both in the scenario described in connection with figure 1 and when a UAProf is 
10 updated during an already established session the UAProf profile changes are 
changes to the terminal's (e.g. mobile phone's) settings or characteristics (e.g. 
the user may change the desired gray scale level for images, etc.). 

When a WSP request is issued, the terminal may provide additional information 
15 or override or augment the basic UAProf already cached at the WAP gateway. 

The UAProf profile in the terminal consists of actual profile data and/or Uniform 
Resource Locators (URLs) pointing to the actual data stored on an origin server 
somewhere in the network. The latter is especially useful to point to data that is 
the same for all users of a particular terminal type, e.g. hardware 

2 0 characteristics. Standard attributes values pointed at by the URL can be 

overridden by attribute values e3cplicitly specified in the terminal's profile. E.g. 
user preferences override standard settings. The level of overriding in UAProf is 
thus on attribute levd. 

25 In the UAProf specification, the terminal provided with attribute values may 
override the default settings stored on an origin server in the network. 

In the mobile Intemet world, users will increasingly have more than one user 
device, e.g. a laptop computer, a communicator or a mobile phone, to access an 

3 0 application. These user devices have diflferent capabilities with regard to screen 

size, screen resolution, screen colors, memory, processor capacity, browser etc. 
A laptop computer and a communicator could be coxmected via a mobile 
terminal to the mobile network and are then concerned as attached devices. 
Furthermore, terminals could have other types of attached devices, like digital 
35 cameras, MP3 players, GPS systems, text-to speech converters etc. 
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In order to provide a user with a relevant and valuable service it would be 
necessary for the application that provides the service, to be adapted to the 
user's terminal and to the attached devices. This adaptation can mean that the 
5 information formatting or the information itself is adjusted to the terminal 

capabilities. An example of adjusting the information is when an application only 
sends a summary of an article in a newspaper instead of the whole article. 

By terminal capability is meant the combined capability of the terminal and the 
1 0 attached device that in some cases only depends of the capability of the attached 
device. 

As stated above the technique used today provides for profile changes reflecting 
changes to the client's (terminal's) settings and characteristics and not taking 
1 5 into account the capability of devices attached to the client. 

The object of the invention is to be able to customize the information sent from 
an application server to a terminal depending of the capabilities of devices 
attached to the terminal. 

20 

Summary of the invention 

The above-mentioned objects are achieved by the invention according to the 
characterizing portions of the independent claims. 

2 5 Preferred embodiments are set forth in the depoident claims. 

Thus, the wireless transmission protocol used for co mmuni cation between a 
terminal and an application also includes, in addition to the te rmin a l profile, an 
attached device's profile that is dynamically updated with data related to a 
30 device attached to the terminal. 

The profile changes of the attached device's profile according to the present 
invention do not exclude changes to the terminal profile. 

35 Short description of the appended drawings 
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Figures la and lb illustrate schemiatically the transmission and the wireless 
protocol, respectively, used in the prior art. 

Figure 2 is a schematic.illustrating of a communication system where the 
present invention is applicable. 
5 Figure 3 illustrates a block scheme of a User Agent Profile (UAProf) according to 
the present invention. 

Figure 4 illustrates a preferred embodiment of the invention where an attached 
dcx-icc is wirelessly attached to the terminal using the Bluetooth protocol. 
Figure 5 schematicallsr illustrates the commimication between a terminal and an 
10 application server according to the present invention. 

Figures 6a and 6b illustrate a first scenario where the present invention is 
implemented. 

Figures 7a and 7b illustrate a second scenario ixiiere the present invention is 
implemented. 

1 5 Figures 8a and 8b illustrate a third scenario where the present invention is 
implemented. 

Figures 9a and 9b illustrate a fouirth scenario where the present invention is 
implemented. 

Figure 10 illustrates a fifth scenario v/here the present invention is implemented. 
2 0 Figure 1 1 illustrates a preferred embodiment of the present invention. 

nptailftri d escription of preferre d #>mlinHiTni>ritR nf t he invention 

Figure 2 is a schematic illustrating of a commtmication system where the 

present invention is applicable. 

25 The system comprises a terminal 2, e.g. a mobile phone, adapted to 

communicate with an application 4 in an application server via the mobile 
network and the Internet 10 using a wireless transmission protocol, e.g. WAP or 
alternatively HTTP. In the figure is the WAP gateway between the terminal and 
the application server omitted for sake of clarity but it shoiild be understood 

30 that the communication between the terminal and the WAP gateway is partly 
wireless. Any known commxmication media, e.g. the Internet, could perform the 
commxmication between the gateway and the server. According to an alternative 
embodiment the WAP gateway is omitted whereas there is an end-to-end 
coimnunication between the terminal and the application server. 
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The system also comprises one or many devices 12 attached to the terminal. The 
attached device 12 may be e.g. a laptop computer, an MP3 player, a digital 
camera, a text-speech converter, a parking meter, a vending machine, a printer 
or any device adapted to be connected to a terminal. The attached device may be 
5 connected to the terminal 2 via any conventional electrical or optical cable or via 
the air interface using e.g. a short distance wireless protocol, e.g. the Bluetooth 
protocol, or by using an infrared link. 

The cormection from the terminal to the application is made via a cell\ilar 
1 0 network and the Internet using for example Transmission Control 

Protocols/Internet Protocols (TCP/IP). The TCP/IP protocol specifies the 
addressing of nodes on the Internet and provides a method of sending packets of 
data from one node to another. 

15 Figure 3 illustrates a block scheme of a User Agent Profile (UAProf) according to 
the present invention. UAProf comprises a terminal profile 8 and an attached 
device's profile 16. The terminal profile comprises difGsrent attributes, e.g. 
hardware attributes 18, software attributes 20, browser attributes 22 and 
auxiliary attributes 24. 

20 The attached device's profile 16 comprises a number of components 26,28,30, 
each representing a different device. Each component is provided with relevant 
attributes 32,34,36, respectively, that may be hardware, software or browser 
attributes. 

25 According to a preferred embodiment of the present invention the attached 
device's profile is implemented by defining a new schema in UAProf which is 
allowed \mder the specifications for UAProf. The new schema implementing the 
attached device's profile must comply with specifications that can be found in its 
entirety in "Wireless Application Group, User Agent Profile Specification" 

30 flvailftble at www.waDforum.oro . 

A schema includes components and components in turn comprise of attributes. 
A schema may be regarded as a complete profile structure/ grammar. 
Components are e.g. Tiardware characteristics", "software characteristics", 
**browser" and an attribute is e.g. "screen size". Thus, the schema defines the 

35 structure of the profile and the profile itself can thus be seen as instantiation of 
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a schema: i.e. the profile is a schema filled with actual data or pointers to data. 
WAP UAProf uses Resource Description Framework {RDF) for defining the 
structure/ grammar of a schema, component and attribute. The above- 
mentioned concept using a schema is applied according to a preferred 
5 embodiment of the invention to define an attached device's profile. E.g. when a 
device is attached to a mobile phone (e.g. with Bluetooth) the device informs the 
phone about its capabilities by sending its profile. As long as the profile sent has 
a schema structure that complies with the constraints specified in WAP UAProf 
(and RDF), the phone will be able to understand it. 

10 

According to a preferred embodiment of the invention the attadied device is 
wirelessly attached to the terminal using the Bluetooth protocol for 
communication. This connection is schematically illustrated in figure 4. Figure 4 
shows capability handlers 38,40 and capability data means 42,44 arranged in a 
15 terminal (to the right in the figure) and in an attached device (to the left), 
respectively. The capability handler updates the capability data means in 
response of an attached device's profile received firom an attached device. This 
update is made either in that the attached device automatically sends its profile 
to the terminal when it is connected or in that the terminal sends a terminal 

2 0 capability request to the attached device requesting the device's profile. 

In figure 4 the terminal requests the profile firom the attached device. The 

TCP/IP on top of the Bluetooth protocol is used. The following procedure is 

perfcmned with rrferences to l^ure 4: 
25 (1) A Bluetooth connection is established. 

(2) The capability handler 38 in the terminal discovers that there is a new 
device attached and sends a terminal capability enquiiy request to the 
attached device. The request is handled by an attached device capability 
handler 40. 

3 0 (3) The attached device capability handler 40 reads its capability data (i.e. the 

attached device's profile) firom an attached device capability data means 44 
provided in the attached device and sends it back to the terminal in 
response of the terminal capability enquiiy request 
(4) The terminal's capability data means 42 is updated with the received 
35 profile. 
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Figure 5 schematically illustrates the communication between a tenninal 2 and 
an application server 4 comprising an application. If devices are attached to the 
terminal the capability data means is provided with the attached device's profile. 
5 The capability data means may be updated in many different ways, e.g. 
according to the above-described procedures. 

According to a preferred embodiment of the invention the application server 
requests from the terminal its capabilities (profiles) both regarding the terminal 
1 0 itself and any attached device's capabilities (profiles). This request may be 

transmitted via a WAP gateway or other nodes using other protoa}ls. The part of 
the radio protocol used in the intermediate nodes between the terminal and the 
application server is not a part of the present invention and is therefore not 
described herein. 

15 The following procedure is performed with references to figure 5: 

(1) A pre-requisite is that a data channel is established between the terminal 
(mobile phone) and the application server using packet data or circuit data. 
Other protocol such as WAP on SMS coidd also be used. 

(2) An application would like to find out the capability of the terminal and 

20 sends a terminal capability enquiry request to the terminal. The capability 

handler in the terminal is connected to the TCP stack via a port number. 
The application sends the request to that port number on the terminal and 
the request ends up in the capability handler in the mobile phone. This 
addressing is well known technology and is therefore not further described 

25 herein. 

(3) The terminal's capability handler then reads out the capability data (profile) 
from the capability data means, including both attached devices' 
capabilities and terminal's capabilities, and sends the result (the profile) 
back in response to the terminal capability enquiry request. 

30 

The attached devices or ad-hoc devices may be divided in three different tjrpes: 
substituting devices, complementary devices and sporadic devices. The type of 
device determines whether or not the capabilities of the devices will influence the 
profiOle of the used wireless protocol. 

35 
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The proffle of a substituting device (partly) overrules (overrides) some of the 
mobile phone's profile attributes (e.g. when a laptop is attached, the laptop's 
hardware/ software/browser attributes can overrule the phone's attributes when 
a session is set-up). 

5 

The profile of a complementary device is an addition to the mobile phone's 
profile. 

The profile of a sporadic device is not included in the mobile phone's profile 
10 since this device cannot be considered an add-on to the phone's device to be 

taken into accotmt by the application when deciding on information format and 
content. Examples of sporadic devices are a parking meter, a vending machine 
or a printer. 

15 Apart firom the situation described in connection with figures la and I t., which 
is already used today, five principally difierent situations or scenarios will be 
described in order to illustrate the present invention. 

The first scenario is illustrated in figure 6a. An attached device 12, e.g. a text-to- 

2 0 speech converter, establishes a session with a terminal 2, e.g. a mobile phone 

(illustrated above in ^gure 6a). This may be performed prior the terminal 
establishes a mobile Internet session with an application server 4. Figure 6b 
illustrates the protocol profiles, UAProf, comprising the terminal profile 8 with 
attributes and the attached device's profile 16 including a camera component 46 
25 with its attributes 48. 

In »HiQ first scenario, e.g., a text-to-speech converter is attached to the terminal. 
The application may take this into accoimt when deciding what information to 
deliver and how this information is delivered. The text-to-speech converter is a 
complementary device and therefore the profile sent fi-om terminal to application 

3 0 contains the capabilities of both the terminal and the text-to-speech converter. 

In the second scenario an attached device establishes a mobile Internet session 
with the application via the terminal that is relaying the session. In this case the 
attached device works as a substituting device. 
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The second scenario is illustrated in figure 7a. An attached device 12, e.g. a 
laptop computer, establishes a session with a terminal 2, e.g. a mobile phone 
(illustrated above in figure 7a). Hus may be performed prior the terminal 
establishes a mobile Internet session with an application server 4. Figure 7b 
5 illustrates the protocol profile, UAProf, comprising the attached device's profile 
including a laptop component 50 with its attributes 52. 
In this second scenario the attached device will send its profile along with the 
session establishment. The application server will receive the profile of the 
attached dcxicc and not that of the mobile phone, since the phone is acting as a 
10 sort of router. In this scenario the WAP/HTTP stack terminates in the device, 

which means that the WAP/ HTTP sessions are set up transparently through the 
mobile phone. The profile will only contain the capabilities of the attached 
device, e.g. the laptop from which the mobile Internet session is established. 

15 In the third scenario an attached device establishes a mobile Internet session 
with the application and the terminal is acting as a gateway in between. 
The third scenario is illustrated in figure 8a. An attached device 12, e.g. a laptop 
computer, establishes a session with a terminal 2, e.g. a mobile phone 
(illustrated above in figure 8a). This may be performed prior the terminal 

20 establishes a mobile Internet session with an application server 4. Figure 8b 
illustrates the protocol profiles, UAProf, comprising the terminal profile 8 with 
attributes and the attached device's profile 16 including a laptop component 50 
with its attributes 52. 

In this scenario the attached device sets up a Mobile Internet session with the 
25 mobile phone and the mobile phone sets up a session with the application. The 
WAP stack is terminated in the mobile phone, but the information received from 
the application does not terminate in the phone but is passed on fi-om the phone 
to the attached device. The profile sent, includes the capabilities of both the 
mobile phone and of the attached device that initiated the Mobile Internet 
3 0 session with the mobile phone. Other devices that may be attached to the mobile 
phone (e.g. a text-to-speech converter) are not included in the profile, since it is 
the initiating device that is preferred by the user and therefore is the other 
attached devices not relevant in this case. In this case the attached device works 
as a complementary device. 

35 
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In the fourth scenario the terminal has already established a mobile Internet 
session with the application when a new device is attached to the terminal. 
The fourth scenario is illustrated in figure 9a. A terminal 2» e.g. a mobile phone, 
has established a mobile Internet session with an application server 4 
5 (illustrated above in figure 9a). An attached device 12, e.g. a camera, is then 
attached to the terminal and establishes a session with the terminal 2. Figure 9b 
illustrates the protocol profiles, UAProf, comprising attached device's profile 16 
including a camera component 46 with its attributes 48. 
This scenario is applicable, for example, when entering a car equipped with a 

10 te3ct-to-speech converter and the user is asked "Aether the application needs to 
be informed about the new device available. This will allow the application to 
reconsider the way the information is presented. The question is not asked for 
sporadic devices like parking meters, vending machines or printers. 
Since there is already an established mobile Internet session between the mobile 

15 phone and the application server, the application has already received a profile 
from the phone. Therefore a DifLProfile needs to be sent to the application 
server, specifying what the additional capabilities are. This Di£LProfile is 
illustrated iii figure 9b. 

20 In the fifth scenario the application requests the profile prior to establishing a 
mobile Inti^rrLet session to the terininal. The application wants to send out 
information to the terminal and thereby initiates the session and asks the 
terminal and device for its c£^abilities, compared to the normal case when the 
terminal initiates, and directly sends its and its attached devices capabilities. 

2 5 The fifth scenario is illustrated in figure 10. An application servo: 4 requests the 

profile from a terminal 2, e.g. a mobile phone, to be able to tailor the push 
information format and content to the attached device 12, e.g. a camera or an 
MP3-player. The following profile is then returned from the terminal to the 
application: terminal profile + attached device's profile. 

3 0 The application will also get the entire profile of the terminal, not overruled by 

any substituting devices' profiles, since the application mi^t decide to push the 
information to the phone rather than to one of the substituting devices. 
If there is currently no ongoing session between the terminal and the WAP 
gateway, and the WAP gateway does not store the profiles beyond the duration of 
35 a session, the WAP gateway (or the application) can query the mobile phone. 
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The first four scenarios are pull scenarios, i.e. user initiated, and the last one is 
a push scenario, i.e. application initiated. 

5 Figure 1 1 illustrates how an application in an application server 4 can retrieve 
an attached device's 12 capabilities prior to pushing information in order to be 
able to tailor the information format and content. The following procedtire is 
performed with references to figure 1 1: 

(1) . A terminal e.g. a mobile phone enters a car that is equipped with a text-to- 
10 speech converter. An ad-hoc network is established between the mobile 

phone 2 and the attached device. 

(2) . The profile of the complementary device (in this case the text-to-speech 

converter) is sent to the mobile phone that updates its profile record. 

(3) . The user of the mobile phone subscribes to news fi-om a content provider 
15 (the appUcation server) and the news application (located in the application 

server) decides to push the latest news information to the mobile phone. 

(4) . A terminal capability request (i.e. what is the capability of the mobile phone 
and any ad-hoc connected devices) is sent to the WAP gateway 54. The WAP 
gateway is capable of sending WAP push messages to the mobile phone. A 

20 MSISDN number is supplied in the request. The MSISDN number could for 
example be fetched by the application fi"om the personal information related 
to the news subscription. The WAP gateway sends the push request to the 
mobile phone. In figure 11 PLMN stands for Public Land Mobile Network and 
could be e.g. UMTS (Universal Mobile Telephone System), GSM (Global 

25 Service for Mobile transmission) or GPRS (General Packet Radio Service). 

It should be noted that the terminal capability request could be sent by the 
application direct. The use of a WAP gateway illustrated here is only one 
possible solution. 

30 The terminal capability request ends up in the mobile phone. 

The now updated profile is sent back to the application server. 

(5) . With the new information the application can adopt the information to the 
new capabilities. In this example the news content is converted to a speech 
mark-up language. ^ 
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The speech mark-up language hews content is then sent to the mobile phone 
that uses the text-to-speech converter to present the information to the user. 

The present invention is not limited to the above-described preferred 
embodiments. Various alternatives, modifications and equivalents may be used. 
Therefore, the above embodiments should not be taken as limiting the scope of 
the invention, which is defined by the appendant claims. 
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Claims 

1 . Data communication system comprising a terminal (2) adapted to 
communicate with an application (4) using a wireless transmission protocol (6) 
includingaterminal profile (8), characterized in that said wireless 

5 transmission protocol also includes an attadied device's profile (16) that is 
updated with data related to devices attached to the terminal. 

2. Data conmnmication system according to claim 1, characterized in 
that the update of the attached device's profile is terminal initiated. 

10 

3. Data communication system according to claim 1, characterized in 
that the update of the attached device's profile is attached device i n i tiated. 

4. Data communication system according to claim 1, characterized in 
15 that the application can retrieve the terminal profile and the attached device's 

profile from the terminal. 

5. Data commimication system according to any preceding claim, 
characterized in that said attached device's profile is dynamically 

20 updated. 

6. Data communication system according to any preceding claim, 
characterized in that said attached device's profile comprises data 
related to the capabilities of the attached device. 

25 

7. Data communication system according to any preceding claim, 
characterized in that said wireless transmission protocol is the 
Wireless Application Protocol (WAP). 

30 8. Data commimication system according to claim?, characterized in 
that said attached device's profile is implemented as a new schema in the User 
Agent Profile (UAProf) in WAP. 

9. Data communication system according to any preceding claim, 
35 characterized in that said terminal is a mobile phone. 
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15 

10. Data commtmication system according to any preceding claim, 
characterized in that said device attached to the tenninal is wirelessly 
attached using the Bluetooth protocol. 

5 

1 1 . Data communication system according to any preceding c laim , 
characterized in that said attached device is a substituting device, 
wherein the profile of a substituting device partly overrides the terminal's profile. 

10 12. Data communication system according to any preceding claim, 

characterized in that said attached device is a complementary device, 
wherein the profile of a complementary device is an addition to the terminal's 
profile. 

1 5 13. Data communication system according to any preceding cdaim, 

characterized in that said attached device is a sporadic device. 

14. Method ia a data communication system comprising a te rm i n al provided 
with a wireless transmission protocol including a terminal profile, 

20 characterized in that said method.comprises the following step: 

i) update an attached device's profile included in said wireless transmission 

protocol with data related to a device attached to the terminal. 

15. Methodaocordingto claim 14, characterized in that the attached 
2 5 devices profile in said wireless transmission protocol is dynamically updated. 

16. Methodaocordingto daim 14 or 15, characterized inthatsaid 
method further comprises the following steps: 

ii) transfer the attached device's profile to an application server, and 

30 iii) tailor an application to be transferred from the application server to the 

attached device, via the terminal, in accordance with the attached device's 
profile. 
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